Identity management systems are information systems that support the management of identities. In particular, an identity management system establishes the identity of a subject or an object by linking a name (or number) with the subject or object. The identity management system may also describe the identity, for example, by assigning one or more attributes applicable to the particular subject or object to the identity. The identity management system may also modify the identity, such as by linking a new or additional name, or number, with the subject or object and/or change one or more attributes applicable to the particular subject or object. The identity management system can record and/or provide access to logs of activity by the identity.
One of the cornerstones of establishing a secure network environment is making sure that access is restricted to people who have the right to access the network. This access is allowed when the user can authenticate to the identity management system, meaning the user can verify his identity. The authentication may be managed by a public key infrastructure (PKI), such as implemented by a certificate system. For PKI, users and machines may present digital certificates to verify their identity. A digital signature is a mathematical representation of a message, using public key cryptography, which identifies the originator of the message, in a non-forgeable manner. Public key cryptography requires the use of two mathematically related keys—a public key and a private key (collectively referred to as a key pair). The private key is kept private by a single owner, and is not distributed to anyone else. The owner uses his or her private key, in conjunction with cryptographic algorithms, to digitally sign a message. The public key is made public, and can be used by anyone to verify the digital signature on a message. The fact that these two keys are mathematically related ensures that only a single private key can generate a digital signature that is verifiable by the corresponding public key, making the digital signature unforgeable. Public key encryption also allows protection of the confidentiality and integrity of a message or file. Using public key encryption the message or file is encrypted using the public key, which can only be decrypted using the private key. These asymmetric key algorithms allow one key to be made public while retaining the private key in only one location. A digital certificate, commonly referred to as a certificate, is an electronic document used to identify an individual, a server, a company, or another type of entity and to associate that identity with a public key. The digital certificate binds a person's identity to his or her public key, and consequently, to his or her private key, and may be used to verify digital signatures. Digital certificates and digital signatures then provide the foundation for secure transactions over a network, such as the Internet.
Certificate authorities (CAs) validate identities and issue certificates. CAs can be either independent third parties or organizations running their own certificate-issuing server software, such as a certificate system. Before issuing a certificate, a CA must confirm the user's identity with its standard verification procedures. The certificate issued by the CA binds a particular public key to the name of the entity identified by the certificate. In addition to the public key, the certificates include the name of the entity it identifies, an expiration date, and the name of the CA that issued the certificate.
These certificates can be stored on tokens, also referred to as smart cards, smart card tokens, security tokens, hardware tokens, hard token, USB tokens, cryptographic tokens, key fobs, or other hardware security modules (HSMs). The token may be a physical device that an authorized user of computer services is given to ease authentication. Tokens can store a certificate that is used for authenticating the identity of the owner. For example, when a user inserts a smart card into a system, the smart card presents the certificates to the system and identifies the user so the user can be authenticated over the network.
In a conventional system, a token client has a client application, such as an enterprise security client (ESC), which manages the token, and interacts with a token processing system (TPS) of a certificate system. The TPS, which acts as a registration authority (RA) of the CA, coordinates the enrollment process, and acts as a gateway between the token client and the certificate system. The TPS communicates with a token key service (TKS), which maintains master keys for tokens, and may store symmetric keys associated with the token. These keys may be derived from a single master key combined with smart card serial number or card universal identification (CUID) number. The TPS may also communicate with a data recovery manager (DRM), which maintains a database of encrypted private keys for recovery purposes. The DRM can archive the private key for later recovery. Archiving private keys offers protection for users, and for information, if that key is ever lost. When information is encrypted by the public key, the corresponding private key must be available to decrypt the information. If the private key is lost, the data cannot be retrieved. A private key can be lost because of a hardware failure or because the key's owner forgets the password or loses the hardware token in which the key is stored. The TPS also communicates with the CA to issue a certificate in response to the public key information and certificate enrollment request received from the token client. Examples of this conventional system are described in U.S. Patent Publication No. 2008/0022121, U.S. Patent Publication No. 2008/0022088, and U.S. Patent Publication No. 2008/0019526, all filed Jun. 6, 2006 and commonly assigned to the assignee of the present application.
When the private key of the token is lost or damaged, the token client can initiate a key recovery process. For example, the ESC can send a key recovery request to the TPS, which forwards the request to the CA to recover the private key. In the conventional system, the DRM encrypts the recovered private key with a password provided by an agent of the CA and delivers the encrypted private key to the token client. The agent then verbally communicates the password to the owner of the token in order to decrypt the encrypted private key. The conventional systems may be limited to token clients and require human interaction to verbally communicate the password to maintain security of the private key.